[レポート] re:Invent 2019 #STG208 バックアップリストアとDRをAWSで行うには #reinvent
こんにちは。
ご機嫌いかがでしょうか。
re:Invent2019 に参加するためラスベガスへ来ています吉井 亮です。
はじめに
本記事はAWS re:Invent 2019のセッション「STG208 - Backup-and-restore and disaster-recovery solutions with AWS」 のレポートです。
セッション概要
災害、障害、脅威はあらゆる形と規模で発生し、ビジネスに大きな影響を与えます。 このセッションでは、クラウドへのハイブリッドモデルとクラウド内のバックアップとDRを使用して、 バックアップと災害復旧(DR)アーキテクチャを近代化する方法を学びます。 このセッションには、お客様がバックアップとDRの実装で使用しているさまざまなアーキテクチャ、およびバックアップとDRに使用されるAWSサービスとビルディングブロックの説明が含まれています。 また、AWSバックアップおよびDRパートナーのサードパーティバックアップおよびDRツールを利用する顧客が採用している一般的なアーキテクチャについても説明します。
スピーカーは以下の三人。
Jody Kirk
Creighton Swank
Juan Mejia
AWS でのバックアップの基本がつまったセッションでした。
なぜバックアップが必要か
万が一のデータロスによる影響を最小限に留めるためです。
データロスはビジネスの後退、顧客からの信頼損失などにつながる重要事態です。
バックアップウィンドウの適切な設定はリカバリ時間の短縮につながります。
バックアップ頻度を短くすること、保存期間を長くとることは
データロスのリスクを減らします。
一方でバックアップにかかるコスト増を引き起こします。
リスクとコストのバランスをとって設計を行ってください。
バックアップに対する要求
バックアップに対する要求を明らかにしましょう。
- 守るべきアプリケーションは?
- ビジネス影響の解析
- RPO と RTO を定義
- コンプライアンスを考慮
伝統的なバックアップ
ローカルにバックアップサーバーを配置、
バックアップサーバーを介してローカルディスクまたはテープへバックアップ、
そのテープを遠隔地保管をしていました。
クラウドバックアップの利点
既存の方式を使うことができる
既存の方式 (前述したような) のままバックアップ先をクラウドへ変えるだけでも
クラウドバックアップの利点を享受できます。
費用対効果が高い
言うまでもなく pay as you go です。
テープメディアの在庫を持つ必要はありません。
過剰なディスクアレイも不要です。
物理テープと管理が無くなる
耐用年数と必要容量を計算して毎年買い足すといった作業が要らなくなります。
また、耐用年数が過ぎたテープの廃棄や中のデータ管理も不要です。
S3 and S3 Glacier
99.999999999% の耐用性 (データの失いにくさ) で設計されています。
バックアップ用途に向いています。
コンプライアンス対応の遠隔地保管
S3 を Cross-Region でレプリケーションすれば
例えば 100km 離れた場所に遠隔地保管しないとならないといった
コンプライアンスに準拠可能です。
File Gateway
ここからは AWS サービスを使ったクラウドバックアップの紹介です。
オンプレミスのアプリケーションがファイルベースのバックアップを
S3 へ保管する方式です。
File Gateway はオンプレミスにデプロイします。
既存のディスクまたはテープ装置を S3 へ置き換えます。
ユースケース
- オンプレミスアプリケーションのファイルベースバックアップ
- ハイブリッド環境での活用
- 低レイテンシーの S3 アクセス (オンプレミス)
Tape Gateway
S3 をバーチャルテープとしてオンプレミスサーバーに見せる方式です。
既存のバックアップソフトウェアが AWS に対応していれば
バックアップ先を変更するだけで既存のバックアップをそのまま使えます。
ユースケース
- 既存バックアップソフトウェアをそのまま使いたい
- S3 Glacier へのアーカイブ
Volume Gateway
クラウドをバックエンドにしたブロックストレージ (ボリューム) を提供します。
Volume Gateway はオンプレミスにデプロイします。
オンプレミスのサーバーからは iSCSI のストレージとして認識されます。
バックアップしたブロックストレージは
EBS スナップショットに変換可能です。
ユースケース
- オンプレミスデータのバックアップ
- オンプレミスボリュームのクラウドマイグレーション
- DR
EBS スナップショット
今まではハイブリッド環境でクラウドバックアップでしたが
ここからは AWS 環境でのバックアップです。
ブロックストレージのバックアップです。
裏側は S3 (ユーザーは意識しない) なので耐用性は十分です。
ユースケース
- EC2 バックアップ
- DR
EFS
NFS のマネージドサービスです。
ファイルベースのバックアップを行う際の選択肢の1つです。
AWS Backup と組み合わせて二重のバックアップとしてデータを保護します。
ユースケース
- Warm Recovery のためのバックアップ先
- Oracle、IBM、SAP などの製品ネイティブのバックアップツールの保管先
- AWS Backup を使って EFS のコールドバックアップを S3 へ保管
これらを活用して考えられるバックアップパターン
- オンプレミスのバックアップを AWS に置く
- オンプレミスのバックアップを AWS に置きつつ、AWS をリモート/ブランチオフィスにする
- SaaS バックアップモデルを AWS に構築する (パートナーソリューション)
- オンプレミスのバックアップサーバーから EC2 のバックアップを管理 (パートナーソリューション)
- AWS 上のバックアップサーバーから EC2 のバックアップを管理 (パートナーソリューション)
AWS Backup
AWS Backup はコンプライアンスを集中管理し、バックアップを自動化し、サービス横断を実現します。
AWS Backup の利点。
- バックアップのスケジュールとライフサイクルの管理
- バックアップアクティビティ、セキュリティ、レポートの一元管理
- アーカイブの一貫性とコンプライアンス要件の充足
事例
Caterpillar 社の事例になります。
バックアップに誰も気をかけなかった頃
- バックアップは高すぎ
- バックアップがパフォーマンスに影響している
- なぜバックアップを複製するの?
- このデータベースはそのバックアップをサポートしてないんだよ
リストアの重要性に気付いてから
- リストア完了までどれくらい?
- コストは気にしないよ、データが大事だから
- なんで昨晩までしか戻らないの?
よくあることでは無いでしょうか。
リストアする局面までいかないと重要性に気付いてもらえないことは多いです。
バックアップに関する旧来課題
- 初期コストが高すぎる (アプライアンス、ライセンス、メディア)
- 環境間で共用している
- バックアップ/リカバリ 要件の整理
- RPO/RTO の未達
- バックアップのキャパシティプランニング
How Caterpillar backup up/to AWS resources
Caterpillar 社はどのようにバックアップを AWS リソースへ移したのでしょうか?
- "One size fit all" は無いことを知る
- サービスごとに必要な要件は異なる
- 必要に応じて既存の機能も使う
- バックアップは自動化する
- サードパーティツールを使う
- ファイルレベルの一貫性やオンプレミスバックアップなど
タグで管理
EC2 バックアップは自動していますが
個別要件はタグで管理しています。
- バックアップ? yes or no
- バックアップ取得周期
- バックアップウィンドウ
- 世代管理
所感
ハイブリッドにしてもクラウドオンリーにしても AWS でのバックアップは
非常に使い勝手が良くリーズナブルで様々な要件を満たしてくれるソリューションだと思います。
システムをオンプレミスから動かせない事情があっても、、まずはバックアップからクラウドを始めることもできます。
クラウドバックアップにご注目ください。
以上、吉井 亮 がお届けしました。